The present invention relates to a method and an apparatus for normalization of traffic data in networks, such as TCP/IP networks.
The present invention specifically relates to a method and a traffic normalizer designed to normalize traffic data which is simultaneously transferred to a network intrusion detection system and an end-system monitored thereby, in order to eliminate ambiguities while reducing transmission delays or overload situations in the installed traffic normalizer or the related network.
According to Kathleen A. Jackson, INTRUSION DETECTION SYSTEM (IDS) PRODUCT SURVEY, Version 2.1, Los Alamos National Laboratory 1999, Publication No. LA-UR-99-3883, Chapter 1.2, IDS OVERVIEW, intrusion detection systems attempt to detect computer misuse. Misuse is the performance of an action that is not desired by the system owner; one that does not conform to the system's acceptable use and/or security policy. Typically, misuse takes advantage of vulnerabilities attributed to system misconfiguration, poorly engineered software, user neglect and to basic design flaws in protocols and operating systems.
Intrusion detection systems analyse on-line activities of internal and/or external users for forbidden (i.e. invalid) and anomalous (i.e., a typical, inconsistent) behaviour. They are based on the hypothesis that monitoring and analysing network transmissions, system audit records, system configuration, data files and further information can detect misuse. Also see, Dorothy E. Denning, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 2, February 1987, pages 222-232. This information encompasses vast quantities of data which at least partially are processed in real-time preferably in dedicated network processors.
In a publication by Thomas H. Ptacek and Timothy N. Newsham, entitled Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection, Secure Network Inc., January 1998, it is described that known network-based intrusion detection systems are susceptible to direct attacks which are based on an intruders intention of establishing a difference of information provided to an network intrusion detection system and to a monitored end-system that either allows to misuse the network intrusion detection system or the monitored end-system.
Network intrusion detection systems work by predicting the behaviour of networked machines based on packets they exchange. A number of issues exist which make the actual information content of packets captured by an network intrusion detection system ambiguous. A network intrusion detection system is typically implemented in a machine that is entirely different from a system it is monitoring. In addition packets processed in the network intrusion detection system and the end-system are normally taken from different points within a network topology. In many cases it can therefore not be accurately predicted whether packets received by the network intrusion detection system even reach the monitored end-system or are processed in the same manner therein.
An network intrusion detection system can accept a packet that an end-system rejects. An network intrusion detection system that does this makes the mistake of believing that the end-system has accepted and processed the packet when it actually has not. An attacker can exploit this condition by sending packets to an end system that it will reject, but that the network intrusion detection system will think are valid. In doing this, the attacker is “inserting” data into the network intrusion detection system. On the other hand an end-system can accept a packet that an network intrusion detection system rejects. An network intrusion detection system that mistakenly rejects such a packet misses its contents entirely. This condition can also be exploited, this time by slipping crucial information past the network intrusion detection system in packets that the network intrusion detection system is to strict about processing. These packets are therefore “evading” the scrutiny of the network intrusion detection system as described by Ptacek et al.
In order to avoid ambiguities in the traffic streams reaching the network intrusion detection system and a monitored end-system it has been proposed to use a traffic normalizer that processes a data traffic forwarded to a site in such a way that potential ambiguities are eliminated.
In TCP/IP networks ambiguities are often related to fragmentation of datagrams which in sizes limited by the given maximum transfer units (MTU) are transferred across networks and sub-networks.
As described by Douglas E. Comer in INTERNETWORKING with TCP/IP, PRINCIPLES, PROTOCOLS, AND ARCHITECTURES, 4th EDITION, Prentice Hall 2000, chapter 7, pages 95-114, in the ideal case an entire datagram of the IP layer fits into one frame that normally travels across many types of physical networks as it moves across an internet to its final destination (regarding layering in TCP/IP environments see pages 187-191).
A datagram of IP version 4 is limited to a maximum size of 65,535 octets. The physical network treats the entire datagram, including its header as data encapsulated in the data area of the frame. Each packet switching technology places a fixed upper bound on the amount of data that can be transferred in one physical frame. For example, Ethernet limits data content to 1500 octets, while FDDI allows 4352 octets of data per frame. The limits are referred to as maximum transfer units (MTU). Allowing datagrams to be larger than the minimum MTU, called the path MTU (see Comer, page 702), in an internet therefore means that a datagram not always fits into a single network frame. Instead of designing datagrams that adhere to the constraints of physical networks, TCP/IP software chooses a convenient initial size and divides large datagrams into fragments that can be encapsulated in frames of a network that has a smaller MTU (see Comer, pages 102-104).
As shown in FIG. 1, hosts A and B are attached to different Ethernets which have a maximum transfer unit MTU of 1500 octets. Thus, both hosts can generate and send datagrams up to 1500 octets long. However, the path between said Ethernets includes a network with a maximum transfer unit MTU of 620 octets. If host A sends host B a datagram, larger than 620 octets, router 1 will split the datagram into fragments that can be encapsulated in a frame of the underlying network.
As shown in FIG. 2, a datagram with a datagram header and 1400 octets of data will for example be split into two fragments containing 600 octets of data each and one fragment containing 200 octets of data. The headers of the fragments 1 and 2 have the MORE FRAGMENTS bit set in the fragment headers, indicating that further fragments will follow (see Comer, page 98, FIG. 7.3, datagram format).
The fields in the datagram header, IDENTIFICATION, FLAGS, and FRAGMENT OFFSET, control fragmentation and reassembly of datagrams.
The FRAGMENT OFFSET field in the fragment header specifies in units of 8 octets the offset in the original datagram for the data being carried in a fragment.
Most of the content of the fragment header is duplicated from the originating datagram with an exception of the fields FLAGS and FRAGMENT OFFSET.
Once a fragment has been fragmented the fragments travel as separate datagrams all the way to the ultimate destination where they are reassembled. Field IDENTIFICATION, which is copied to each fragment, allows the destination to know which arriving fragments belong to which datagrams. The receiving machine (FIG. 1, host B) starts a reassembly timer when it receives an initial fragment. If the timer expires before all fragments arrive, the receiving machine discards the received pieces without processing the datagram (see Comer, pages 104-105).
However, in case that host A (see FIG. 1) does not want a datagram to be fragmented it can set the do not fragment bit DF in the field FLAGS to 1. Whenever a router (e.g. router 1) needs to fragment a datagram that has the do not fragment bit DF set, the router discards the datagram and sends an error message back to the source.
Because end-systems (FIG. 1, host A or host B) will reassemble the received fragments, it is important that the network intrusion detection system correctly reassembles the fragments as well. A network intrusion detection system that does not correctly reassemble fragments can be attacked simply by using artificially fragmented packets (see Ptacek, pages 20-23).
FIG. 3 shows such a situation, where an attacker (host B) hides an attack behind two fragments. The attacked host (host A) reassembles the datagram correctly so that data intended for misuse is generated while the network intrusion detection system NIDS does not recognize the attacking situation due to different reassembly of the fragments.
A network intrusion detection system that correctly reassembles fragments may still be subject to attacks. In case that reassembly algorithms of the network intrusion detection system and the monitored end-systems are inconsistent, then an attacker, knowing these weaknesses, could exploit differences in the reassembly procedures in order to attack end-systems while by-passing the network intrusion detection system undetected.
A further problem involves fragmentation overlap, which occurs when fragments of differing sizes arrive in overlapping positions. If a fragment arriving at an end-system contains data that has already arrived in a different fragment, it is possible that the newly arrived data will overwrite some of the old data.
Information required to reassemble fragments of a datagram could therefore be manipulated by an attacker in order to generate overlaps that are handled differently by the network intrusion detection system and the monitored end-systems.
Differences in the systems may arise depending on the order of arrival of the fragments or depending on the position of the overlap. A network intrusion detection system that does not follow the same interpretation of the received fragments is therefore vulnerable to evasion attacks.
FIG. 4 shows a further example of an attack exploiting fragmentation ambiguity. The attacker sends a first fragment covering octets 0 . . . 3 of the data area of the originating datagram and then a second fragment covering octets 3 . . . 5. In the given example reassembly of octets 0 . . . 3 of the first fragment and octets 4 and 5 of the second fragment results in a data string designed for misuse purposes.
If the reassembly algorithm of the attacked end-system favors old and the reassembly algorithm of the network intrusion detection system NIDS favors new data, then the network intrusion detection system NIDS will miss the attack as shown in FIG. 4.
As described above, each “link” within an internet is characterised by a maximum transfer unit MTU which limits the maximum amount of data that can be sent in a physical frame on a given link. A datagram gets fragmented if its size is larger than the maximum transfer unit MTU. In case that the do not fragment bit DF is set and the maximum transfer unit MTU does not allow the encapsulation of the whole datagram in one physical frame, then the router discards the datagram and sends an error message back to the source.
An attacker having knowledge of the network's topology can use the do not fragment DF bit in order to insert datagrams to the network intrusion detection system NIDS while the same datagrams are discarded on their way to the end-system.
In the example shown in FIG. 5, host A sends datagrams that are addressed to host B across a network which comprises three sub-networks having different maximum transfer units MTU.
The attacker may know, that, starting from host A, a datagram is routed through a first and a second network comprising a maximum transfer unit MTU of 1500 octets. From the second network, to which a network intrusion detection system NIDS is attached, the datagram is routed through a third network with a maximum transfer unit MTU of 620 octets before it reaches host B.
Setting the do not fragment bit DF to 1 while selecting a datagram size smaller than 1500 octets and larger than 620 octets would therefore result in a transfer of datagrams to the second network and further to the network intrusion detection system NIDS as well as to the router 3 which however discards the datagrams since fragmentation would be required in order to transfer the datagrams across the third network to host B.
The network intrusion detection system NIDS would therefore be vulnerable to attacks.
Further ambiguities may result from a given network topology in view of the content of the TIME TO LIVE field which is sequentially altered during the journey of a datagram or a fragment across an internet.
As described in Comer, page 106 the TIME TO LIVE specifies how long, in seconds, a datagram is allowed to remain in the internet system. Routers and hosts that process datagrams must decrement the content of the TIME TO LIVE field as time passes and remove the datagram from the internet when its time expires. During normal operation each router along the path from source to destination is required to decrement the TIME TO LIVE field by 1 when it processes the destination header. Thus, in practice, the TIME TO LIVE field acts as a “hop limit”.
An attacker having knowledge of the network's topology can therefore manipulate the TIME TO LIVE field in order to set the “hop limit” to a point located between the network intrusion detection system NIDS and the receiving end-system, i.e. host B.
Knowing the network's topology an attacker can therefore, as with the DF bit, insert datagrams to the network intrusion detection system NIDS while the same datagrams are discarded on their way to the end-system by manipulation of the TIME TO LIVE field.
In the network shown in FIG. 5 it takes two hops (-->router 1 and then-->router 2) from host A to the network intrusion detection system N host B. Setting the TIME TO LIVE field higher than 2 and lower or equal to 4 will allow an attacker, starting from host A, to send and insert datagrams to the network intrusion detection system NIDS which then are discarded on their way to host B resulting in an ambiguity that can be exploited by the attacker.
In [5], M. Handley, V. Paxson, Ch. Kreibich, Network Intrusion Detection: Evasion, Traffic Normalization, and End-End Protocol Semantics, International Computer Science Institute, Berkley, February 2001, the viability of addressing the described problem by introducing a traffic normalizer is discussed, that eliminates potential ambiguities before the traffic is seen by the network intrusion detection system NIDS and a monitored end-system. As a result the network intrusion detection system NIDS, that is monitoring correctly normalized traffic, no longer needs to consider potential ambiguities while interpreting the data stream. FIG. 6 and [5], FIG. 2 show the typical location of the traffic normalizer relative to the network intrusion detection system NIDS and end-systems being monitored.
In order to avoid ambiguities resulting from overlapping fragments, in [5] it is recommended to reassemble incoming fragments in the normalizer rather than forwarding them to the monitored end-system. In case that they are larger than the maximum transfer unit MTU, the datagrams are re-fragmented before they are sent to the monitored end-system.
As explained in [5] a traffic normalizer that reassembles datagrams is vulnerable to stateholding attacks. While the traffic normalizer can remove fragment-based ambiguities by reassembling all fragmented IP datagrams (and if necessary re-fragment the reassembled datagram) the traffic normalizer must hold the fragments in memory before they can be reassembled. An attacker can thus cause the traffic normalizer to use up memory space by sending many fragments of datagrams without ever sending enough to complete a datagram.
Besides the need of memory resources this method burdens a high workload onto the traffic normalizer and causes corresponding delays in delivery of the data to the end-system which may create further problems.
In order to avoid ambiguities resulting from a do not fragment flag DF being set, as described above, in [5] it is recommended to clear the do not fragment flag DF on incoming datagrams.
As described in [5] this measure systematically breaks path MTU discovery which is undesirable. To discover the path MTU, a sender probes the path by sending datagrams with the IP do not fragment flag DF set. It then decreases the size of the datagrams if ICMP error messages report that fragmentation was required. Knowing the path maximum transfer unit MTU allows to select an optimum size of TCP segments so that IP datagrams carrying the segments are as large as possible without requiring fragmentation along the path from the source to the destination (see [4], page 223).
In order to avoid ambiguities resulting from settings of the TIME TO LIVE field, as described above, in [5] it is recommended set the TIME TO LIVE field larger than the longest path across the internal site, i.e. the intranet shown in FIG. 6.
Drawbacks of this measure described in [5] are the brake of traceroute, a program that prints the path to a destination (see [4], page 715), or the occurrence of perpetual loops of datagrams passing through the traffic normalizer thereby consuming the available bandwidth.
It would therefore be desirable to create an improved method and a traffic normalizer designed for normalizing traffic data which is transferred to a network intrusion detection system and to an end-system monitored thereby.
It would be desirable in particular to provide a normalization method that allows to eliminate ambiguities in a data stream while preventing transmission delays or overload situations in the installed traffic normalizer or the related network.
It would further be desirable to create a normalization method which reduces vulnerabilities of network elements while not restricting the use of procedures such as traceroute or path MTU discovery which were created to optimise operating conditions.